D04 Qualitätssicherung

Änderungen

• 2026-10-10 Inhalte aus D02 Projektmanagement integriert, Continuous Integration ergänzt

Änderungen sind weiterhin vorbehalten.

QS im Wintersemester 2026

Eine Software mit offensichtlichen Bugs, oder die nicht das liefert, was der AG wollte, bringt euch für einen erfolgreichen Projektabschluss wenig.

Wir geben dieses Semester vor, dass ihr folgende Qualitätssicherungsmaßnahmen durchführt:

• Code Reviews

• Tests

• Pair Programming

Euer QS-Prozess soll systematisch, durchführbar und überprüfbar sein. Stellt sicher, dass eure Teambegleitung Einsicht in euren Qualitätssicherungsprozess hat.

Siehe auch:

• V04 Iterationen

• Qualitätssicherungsziele

• resources/Website/Begleitvorlesung/Media/2025-10-29 Software Engineering Best Practices.pdf

Code Reviews

In Code schleichen sich gerne Flüchtigkeitsfehler ein, die eine zweite Person beim Drüberschauen findet.

• Jeder Code muss von einem Teammitglied überprüft werden, das ihn nicht geschrieben hat.

• Code Reviews verteilen Wissen im Team: Verständnisfragen stellen und beantworten.

• Verwendung von Checklisten zur Festlegung von Prüfkriterien.

• Festlegen, wann Reviews stattfinden (z.B. vor der Akzeptanz einer Anforderung).

• Aufmerksamkeit auf den Umgang mit Verbesserungsvorschlägen: Feedback konstruktiv geben und annehmen!

• Tools wie Github/Gitlab bieten gute Unterstützung für Code Reviews

  • Beispiel: resources/Website/Begleitvorlesung/2023 und davor/MR-Example-GIMP.html

• Mehr zum Thema:

  • https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/

  • resources/Website/Graphics/Code Review Checklist - Documentation - OpenMRS Wiki.pdf

  • resources/Website/Graphics/Code_review_checklist.pdf

  • https://www.codereviewchecklist.com/

Code-Analyse-Tools

Tools zur Codeanalyse können den Review Prozess deutlich vereinfachen!

• Meist durch Tools (Linter, teilweise als IDE-Plugins) automatisch ausgeführte Analyse des Quellcodes ohne Ausführung der Software

• Oft auf individuelle Bedürfnisse anpassbar

• Wahl des Tools abhängig von Ziel & Programmiersprache

• Je komplexer die Prüfung desto mehr muss mit False Positives umgegangen werden

  • Überprüfung Coding Style

  • Erkennen möglicher (einfacher) Fehler, Code Smells

  • Best Practice Vorschläge

  • Überprüfung auf Sicherheitslücken

• Werden von Teammitgliedern ausgeführt und gefundene Fehler behoben

• Können automatisch per Continuous Integration ausgeführt werden

Heutzutage existieren auch KI-basierte Analyse-Tools, die ähnlich wie statische Analyse dazu verwendet werden können, zusätzliche Probleme zu finden.

Tests

In der Regel sind automatisierte Tests empfehlenswert, die per Continuous Integration laufen. Die Möglichkeiten zur Umsetzung hängen jedoch von den spezifischen Anforderungen und Gegebenheiten eures Projekts ab.

Manuelle Tests

Was sich nicht sinnvoll automatisieren lässt, muss trotzdem systematisch geprüft werden.

• Manuell von Teammitgliedern, die das Feature nicht entwickelt haben, durchgeführter Test

• Gutes Mittel um Aspekte der Software zu testen, die sich schwer automatisiert testen lassen (wie z.B. UI)

• Test-Protokolle werden erstellt und abgearbeitet

• Zeitpunkt zur Prüfung z.B. nach Fertigstellung eines Features

Automatische Tests

Einmal geschrieben, prüfen automatische Tests bei jeder Änderung, dass nichts kaputtgegangen ist.

• Automatisch ausführbare Tests in verschiedenem Umfang (Unit Tests, Integrationstests, Systemtests)

• Ausreichende Anzahl Testfälle (sichergestellt z.B. durch Berechnung der Testabdeckung)

• Werden von Teammitgliedern entwickelt, ausgeführt und gefundene Fehler behoben

Continuous Integration

Was automatisch bei jeder Änderung läuft, wird nicht vergessen.

• Bei jeder Änderung (z.B. Commit oder Merge Request) wird automatisch gebaut, getestet und analysiert

• Zeigt früh, ob die Anwendung noch baut und alle Tests noch funktionieren

• Voraussetzung: automatisierter Build-Prozess, z.B. mit Maven, Gradle, …

• Plattformen, z.B. GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines, …

• Gilt als Best Practice

Pair & Group Programming

Zusammen programmieren findet Fehler, bevor sie entstehen, und verteilt Wissen im Team.

• Dient der Wissensweitergabe – nutzt die unterschiedlichen Erfahrungen im Team

• Konzept: Arbeiten mit kurzen Kommunikationswegen

• Arbeitet gemeinsam im gleichen Raum (auch virtuell!)

• Klassisch: Eine steuert, beide denken

• Auch möglich:

  • Alle arbeiten an verschiedenen Dingen.

  • Bei aufkommenden Fragen werden dynamisch Gruppen gebildet.

  • Group Programming: das ganze Team arbeitet gemeinsam an einer Aufgabe.

• Nicht für jede Kleinigkeit: Setzt es gezielt bei komplexeren Problemen ein und bewertet danach, ob es sich gelohnt hat.

Unterschätzt nicht, wie hilfreich kurze Kommunikationswege sind, um Probleme zu vermeiden, von denen ihr sonst vielleicht gar nichts mitbekommt.